Hi @orerocks - this is the new implementation of the arbitrary waveform in empymod. Could you have a look at your example, and give me feedback (here or in the SimPEG chat) if your example looks OK to you?
Here is a render of your example: https://empymod--253.org.readthedocs.build/en/253/gallery/tdomain/ip_vrm.html

Hi @aignerlukas - this is the new implementation of the arbitrary waveform in empymod. Could you have a look at your example, and give me feedback (here or by email) if your example looks OK to you?
Here is a render of your example: https://empymod--253.org.readthedocs.build/en/253/gallery/tdomain/tem_temfast.html

Looks great. A few general comments:

• "WalkTEM -> Delay necessary? Bandpass filter necessary?": I don't have answers on this, but I think both are good practice:

  1. delay_rst is i think what we usually call "sensor delay" which basically describes the length of pause that happens from when the TX is nominally expected to achieve 0 current and when the timing gates start. It allows for natural variations in the ramp-down. If that's the case, then it should be a user-parameter defaulting to 0.0 seconds.
  2. Aarhus have made good points in the past about including instrumentation filters in modelling workflows, and this is a good example of that. However, most equipment suppliers don't adequately describe their instrument filters. Keeping this around is a good example of how one might do it. But maybe need to include a comment saying that if you don't know what to use, try without one.

• One point that I had a really hard time with on the waveform in my production code was what happens when the waveform doesn't end at t=0, or where the ramp-down starts at t=0, but doesn't finish until later. The simple off-time heuristic in get_time wasn't enough. I ended up having to recompute the times relative to the end of the ramp, and cover a period of at least Ton + Toff. I may be doing overkill but it is working.

Hi @leonfoks - this is the new implementation of the arbitrary waveform in empymod. Could you have a look at your example, and give me feedback (or in any other way) if your example looks OK to you?
Here is a render of your example: https://empymod--253.org.readthedocs.build/en/253/gallery/tdomain/tem_walktem.html

Thank you so much for this feedback @orerocks - very helpful, particularly as I am not too familiar with TEMs!

• I tested the delay. The delay is small compared to the actual times, so it makes little difference, but it does matter. However, it can just be added to the times, as far as I can see, so no need to include it into bipole-routine itself. (This is how I included it now in the reworked WalkTEM example.
• The filter does make a difference at early times, interesting detail what you say about information in this regard. Which means that for many equipment one can not reproduce the responses 100%, crazy. I add a possibility for this (atm just a crude workaround, but I'll polish it).
• About the timing: In the current implementation, I got rid of the heuristic done in get_time - I straight compute the actually required times for the waveform convolution. So I hope that eliminates the problem you stated. If you could test this that would be great!

Pull Request Test Coverage Report for Build 21543096085

Details

• 80 of 80 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.02%) to 99.311%

Totals
Change from base Build 21458375474:	0.02%
Covered Lines:	3170
Relevant Lines:	3192

💛 - Coveralls

Hi @aignerlukas - this is the new implementation of the arbitrary waveform in empymod. Could you have a look at your example, and give me feedback (here or by email) if your example looks OK to you? Here is a render of your example: https://empymod--253.org.readthedocs.build/en/253/gallery/tdomain/tem_temfast.html

Hi, thanks a lot. very nice improvements, I like them. The example renders fine, seems alright to me.

Thank you so much for this feedback @orerocks - very helpful, particularly as I am not too familiar with TEMs!

* I tested the delay. The delay is small compared to the actual times, so it makes little difference, but it does matter. However, it can just be added to the times, as far as I can see, so no need to include it into `bipole`-routine itself. (This is how I included it now in the reworked [WalkTEM example](https://empymod--253.org.readthedocs.build/en/253/gallery/tdomain/tem_walktem.html).

* The filter does make a difference at early times, interesting detail what you say about information in this regard. Which means that for many equipment one can not reproduce the responses 100%, crazy. I add a possibility for this (atm just a crude workaround, but I'll polish it).

* About the timing: In the current implementation, I got rid of the heuristic done in `get_time` - I straight compute the actually required times for the waveform convolution. So I hope that eliminates the problem you stated. If you could test this that would be great!

very intersting topics, which I have been also struggling with in the beginning when working on the TEM FAST.
Here are my 5 cents:
i) for the TEM FAST we found that a 0 delay_rst worked best, but the difference was actually minor. I also didn't fully understand initially what this was doing exactly.
ii) We tested several Bandpass filters for the TEM FAST and compared the modeling results with a commercial code (ZondTEM, which I was using a lot when starting). There was also no way to get actual filter properties from the manufacturer at the time, however we found that no filter resulted in quite large deviations from the forward modeling result of ZondTEM.

Thanks for the feedback @aignerlukas!